The Internet Protocol Multimedia Subsystem (IMS) refers to a core network that supports multimedia services based on a future evolution of 3G networks, where there exists only a single core network supporting convergent voice and data services, i.e., multimedia services. The multimedia services are based on Voice over Internet Protocol for signaling and media transport. An IMS core network consists of a variety of standardized functional elements, including, but not limited to, one or more instances of a Call Session Control Function (CSCF), Breakout Gateway Control Function (BGCF), Media Gateway Control Function (MGCF), Home Subscriber Server (HSS), Media Gateways (MGW), and application server (AS). Signaling within the IMS core network is based on the Session Initiation Protocol (SIP) using any interface compatible with the Internet Protocol (IP). Herein, IMS is defined as the system specified by the Third Generation Partnership Project (3GPP), Third Generation Partnership Project 2 (3GPP2) and European Telecommunications Standards Institute (ETSI) Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN).
In the IMS core network, there is a SIP signaling interface between Serving Call Session Control Function (S-CSCF) and the application server that is known as the IP multimedia Service Control (ISC) Interface. One driver for the ISC interface is for the S-CSCF to include a specific application server in the SIP signaling path based on initial Filter Criteria (iFC), i.e., subscriber data. The iFC is defined on the Home Subscriber Server and passed to the S-CSCF for a subscriber being served by the S-CSCF. Each iFC defines conditions, known as Service Point Triggers (SPT), associated with a SIP message and the identity of the application server to contact if the conditions are met. Also, each iFC has a priority that determines the order which multiple application servers would be contacted when multiple iFC conditions are met. Each application server may pass the SIP request back to the S-CSCF for continued iFC analysis or may provide a final SIP response which ends the iFC analysis.
When an application server is invoked via the iFC interface, there may be a situation in which the application server needs to provide a final response to a received SIP request to perform an intermediate action, in addition to the need to give the SIP request back to the S-CSCF to continue with the iFC analysis when it completes the intermediate action. Illustratively, an intermediate action for an application server may be to play an announcement to an originating party of a SIP INVITE request or perform an interactive voice response exchange before continuing to route the call request towards the destination. Disadvantageously, this situation is not easily accomplished with the current standardized definition of the ISC Interface. The application server may send a new instance of the SIP request to the S-CSCF, but the S-CSCF will start the iFC analysis from the beginning.
One prior art alternative is for each application server with service logic to resume processing after providing a final response to the SIP request. When the application server sends the new instance of the SIP request, the application server may include a special parameter or header. The service provider could modify the iFC for all application servers that match the conditions and have higher priority such that a negative condition is added in the service point triggers. Disadvantageously, this alternative is cumbersome and may not work when large numbers of application servers are involved and complex conditions are defined.